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FOREWORD 


The  National  Computer  Security  Center  is  publishing  A  Guide  to  Writing  the 
Security  Features  User’s  Guide  for  Trusted  Systems  as  part  of  the  “Rainbow 
Series”  of  documents  our  Technical  Guidelines  Program  produces.  In  the  Rainbow 
Series,  we  discuss  in  detail  the  features  of  the  Department  of  Defense  Trusted 
Computer  System  Evaluation  Criteria  (DoD  5200.28-STD)  and  provide  guidance  for 
meeting  each  requirement.  The  National  Computer  Security  Center,  through  its 
Trusted  Product  Evaluation  Program,  evaluates  the  security  features  of 
commercially-produced  computer  systems.  Together,  these  programs  ensure  that 
organizations  are  capable  of  protecting  their  important  data  with  trusted  computer 
systems. 

A  Guide  to  Writing  the  Security  Features  User’s  Guide  for  Trusted  Systems 
expands  on  the  Trusted  Computer  System  Evaluation  Criteria  requirement  for  a 
Security  Features  User’s  Guide  by  discussing  the  intent  behind  the  requirement  and 
the  relationship  it  has  to  other  requirements  in  the  Trusted  Computer  System 
Evaluation  Criteria.  The  guide’s  target  audience  is  the  author  of  the  Security 
Features  User’s  Guide  for  a  specific  trusted  system  undergoing  evaluation  as  a 
trusted  product;  however,  many  of  the  recommendations  apply  to  any  system  that 
must  satisfy  the  Trusted  Computer  System  Evaluation  Criteria  requirements. 

As  the  Director,  National  Computer  Security  Center,  I  invite  your 
recommendations  for  revision  to  this  technical  guideline.  We  plan  to  review  and 
update  this  document  periodically  in  response  to  the  needs  of  the  community. 
Please  address  any  proposals  for  revision  through  appropriate  channels  to: 

National  Computer  Security  Center 

9800  Savage  Road 

Ft.  George  G.  Meade,  MD  20755-6000 

Attention:  Chief,  Standards,  Criteria,  and  Guidelines  Division 


National  Computer  Security  Center 


September  1991 


ACKNOWLEDGMENTS 


The  National  Computer  Security  Center  expresses  appreciation  to  David  M. 
Chizmadia  as  project  manager  and  principal  author  of  this  document. 

We  also  thank  the  evaluators,  vendors  and  users  in  the  United  States  computer 
security  community  who  contributed  their  time  and  expertise  to  the  review  of  this 
document. 


CONTENTS 


FOREWORD  .  ' 

ACKNOWLEDGMENTS  .  ii' 

1.  INTRODUCTION  .  1 

1.1  PURPOSE  .  1 

1.2  SCOPE  .  1 

1.3  ORGANIZATION  .  1 

2.  DEVELOPING  THE  SECURITY  FEATURES  USER’S  GUIDE  .  3 

2.1  AUDIENCE  AND  PACKAGING  .  3 

2.2  PRESENTATION  .  5 

2.3  CONTENT  .  5 

2.3.1  TECHNICAL  SECURITY  POLICY .  6 

2.3.2  IDENTIFICATION  AND  AUTHENTICATION  .  7 

2.3.3  DISCRETIONARY  ACCESS  CONTROL  FACILITY .  9 

2.3.4  ELECTRONIC  LABELS  .  10 

2.3.5  MANDATORY  ACCESS  CONTROL  FACILITY  .  12 

2.3.6  TRUSTED  FACILITY  MANAGEMENT  .  14 

3.  EXAMPLES  OF  SFUG  PRESENTATION  STYLES  .  15 

THE  FEATURE-ORIENTED  SFUG  .  16 

THE  TASK-ORIENTED  SFUG  .  24 

BIBLIOGRAPHY  .  31 


V 


1. 


INTRODUCTION 

PURPOSE 


1.1 


This  guideline  explains  the  motivation  and  meaning  of  the  Department  of 
Defense  Trusted  Computer  System  Evaluation  Criteria  (TCSEC)  requirement  for  a 
Security  Features  Users  Guide  (SFUG),  which  reads  as  follows; 

“A  single  summary,  chapter,  or  manual  in  user  documentation  shall 

describe  the  protection  mechanisms  provided  by  the  TCB,  guidelines 

on  their  use,  and  how  they  interact  with  one  another.”  [TCSEC-,  x.x.4.1] 

The  reader  is  assumed  to  be  the  potential  author  of  a  SFUG;  to  be  familiar 
with  the  basic  principles  of  technical  writing,  computer  science,  and  trusted  systems; 
and  to  have  a  detailed  understanding  of  the  specific  trusted  system  that  will  be 
described  in  the  SFUG. 

1.2  SCOPE 

This  guideline  identifies  and  discusses  the  considerations  that  influence  the 
development  and  evaluation  of  a  SFUG,  such  as  its  audience,  content,  and 
organization.  It  is  intentionally  descriptive,  as  opposed  to  prescriptive,  in  its 
discussion  of  the  SFUG  requirement.  That  is,  it  describes  the  various  approaches 
to  writing  a  SFUG  that  have  been  accepted  by  trusted  product  evaluators  in  the 
past,  without  making  judgments  about  the  “correct”  ones  to  choose— although 
preferred  approaches  may  be  noted. 

Throughout  this  guideline  there  will  be  statements  made  that  are  not  included 
in  the  TCSEC  as  requirements.  These  statements  will  fall  into  three  categories. 
First,  some  describe  a  strongly  recommended  course  of  action:  these  statements 
will  be  prefaced  by  the  word  “should.”  Second,  others  describe  one  of  several 
equally  appropriate  recommended  courses  of  action:  these  statements  will  be 
prefaced  by  the  word  “could.”  Finally,  a  few  suggest  an  optional  course  of  action: 
these  statements  will  be  prefaced  by  the  word  “can.” 

1.3  ORGANIZATION 

The  remainder  of  this  guideline  presents  information  that  may  be  useful  to  a 
writer  developing  a  SFUG.  Chapter  2  discusses  the  developmental  aspects  of 
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writing  the  SFUG,  including  the  audience  and  possible  packaging  options, 
presentation  styles,  and  the  security  topics  that  should  be  addressed  in  the  SFUG 
(as  derived  from  TCSEC  feature  requirements).  Chapter  3  contains  two  example 
annotated  outlines  of  SFUGs  to  illustrate  some  of  the  topics  discussed  in  the  body 
of  the  guideline  and  provide  a  starting  point  for  the  reader  to  develop  a  SFUG.  The 
bibliography  includes  a  list  of  the  documents  accepted  as  SFUGs  for  all  products  on 
the  Evaluated  Product  List  (EPL)  at  the  time  the  guideline  was  published. 
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2.  DEVELOPING  THE  SECURITY  FEATURES  USER’S 
GUIDE 

The  primary  purpose  of  a  SFUG  is  to  explain  how  the  security  mechanisms  in 
a  specific  system  work,  so  that  users  are  able  to  consistently  and  effectively  protect 
their  information.  To  properly  communicate  this  information,  the  SFUG  author  must 
identify  the  audience  for  the  SFUG  and  the  information  that  audience  needs  to  use 
the  security  mechanisms  in  the  system  and  then  select  an  appropriate  way  to 
present  the  information. 

2.1  AUDIENCE  AND  PACKAGING 

The  SFUG  requirement  starts  with  “A  single  summary,  chapter,  or  manual  in 
user  documentation  .  .  .”  “User”  in  this  context  refers  to  a  person  who  uses  the 
system,  but  has  no  special  privileges  to  affect  the  configuration  of  the  system.  The 
user  for  most  general  purpose  trusted  systems  is  often  assumed  to  be  a  person 
with  little  or  no  computer  experience,  but  this  is  not  always  the  case.  For  example, 
the  users  of  the  UNIX(tm)  system  have  traditionally  been  considered  programmers  or 
computer  professionals  with  fairly  extensive  knowledge  of  computer  concepts.  In 
any  system,  the  users  are  the  audience  for  the  SFUG  and  the  SFUG  author  will 
have  to  characterize  them  to  determine  both  the  format  and  the  level  of  discourse 
for  the  material  presented  in  the  SFUG. 

In  many  cases,  the  SFUG  requirement  is  satisfied  by  changing  an  existing 
document,  which  is  one  of  the  reasons  that  the  SFUG  requirement  is  so  general. 
As  stated  in  the  requirement,  the  SFUG  could  be: 

•  A  summary  of  the  security  features  and  user  responsibilities, 

•  A  chapter  devoted  to  these  issues,  or 

•  A  whole  manual  devoted  to  security. 

Some  presentation  schemes  that  previous  participants  in  the  Trusted  Product 
Evaluation  Program  have  used  include: 

•  A  separate  manual  devoted  to  the  general  user  of  the  system  that  covers 
the  security  features  and  responsibilities  pertaining  to  users.  This  is 
usually  the  best  choice  when  a  document  of  this  sort  is  already  in  place 
and  the  security  functions  have  always  been  present  in  the  system  in 
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some  form  anyway.  For  a  system  in  which  user  services  are  provided  by 
individual  subsystems,  one  of  which  provides  all  the  security  functionality, 
and  the  user  guide  is  the  collection  of  user  guides  for  the  individual 
subsystems,  the  SFUG  would  most  likely  be  a  stand-alone  manual 
addressing  only  the  security  issues. 

•  A  subsection  of  the  manual  produced  to  satisfy  the  Trusted  Facility  Manual 
(TFM)  requirement  of  the  TCSEC.  From  a  security  standpoint,  this  is 
considered  unwise,  since  it  tends  to  make  the  system  configuration  and 
vulnerability  information  available  to  anyone  looking  for  information  on  how 
to  use  the  security  features  of  the  system.  From  a  documentation 
standpoint,  it  seems  the  easiest,  since  it  places  all  of  the  security 
discussion  in  one  place  and  allows  a  certain  amount  of  synergy  in  the 
writing  process,  i.e.,  privileged  users  do  many  of  the  same  activities  as 
general  users.  This  approach  eliminates  the  need  to  document  those 
facilities  in  two  places. 

•  A  chapter  or  an  appendix  of  a  user  manual  that  discusses  the  user’s 
security  responsibility  and  then  provides  an  index  to  the  detailed 
discussions  of  individual  functions  that  are  already  part  of  the  general  user 
manual.  An  extension  of  this  could  be  a  small  pamphlet  that  does  the 
same  thing  but  can  be  reproduced  separately  and  given  out  as  needed  — 
something  like  a  pocket  guide  to  system  security. 

Trusted  product  evaluators  tend  to  favor  centralization  of  information,  because 
that  makes  it  easier  to  determine  whether  the  system  satisfies  the  TCSEC  (Orange 
Book)  requirements.  Given  that  bias,  bullet  one  would  usually  be  the  most  preferred 
option,  since  it  satisfies  the  requirement  in  one  unique  place.  Bullet  two  is  a  less 
desirable  option,  because,  in  addition  to  the  procedural  security  considerations,  it 
requires  some  discrimination  to  identify  which  parts  of  the  document  satisfy  the 
SFUG  requirement  and  which  parts  satisfy  the  TFM  requirement.  Bullet  three  is 
least  desirable  for  two  reasons.  First,  it  involves  pointers  to  other  information, 
making  it  more  cumbersome  for  both  evaluators  and  users  to  get  to  some  aspects 
of  the  information.  Second,  there  might  be  a  tendency  to  make  the  document  so 
terse  that  it  excludes  some  information  that  is  relevant  to  system  security. 
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2.2  PRESENTATION 

The  SFUG  provides  the  users  of  the  system  with  the  necessary  background 
and  specific  information  to  use  the  protection  features  of  the  system  correctly.  Its 
purpose  is  twofold.  First,  it  provides  the  information  that  a  user  needs  to  enter  the 
system  and  start  working— within  the  system  security  constraints.  Second,  it 
explains  the  user’s  role  in  maintaining  the  security  of  the  system.  Its  scope  should 
be  limited  to  documenting  only  the  features  available  to  all  users  and  only  the 
responsibilities  that  all  users  have  for  system  security.  To  accomplish  this  purpose, 
within  the  scope,  the  SFUG  should  explain  what  security  means  in  the  system,  what 
security  features  are  present  and  why,  how  the  features  work,  and  how  to  use  the 
features  properly.  The  SFUG  should  be  clear,  concise,  and  complete  to  increase  its 
readability. 

This  information  can  be  organized  either  by  the  security  features  present  in 
the  system  or  by  the  tasks  performed  by  a  user  that  require  the  use  of  these 
features.  A  feature-oriented  presentation  is  more  natural  to  a  user  who  is  already 
familiar  with  the  system.  In  the  SFUG,  this  organization  would  usually  look  like  the 
TCSEC  itself,  with  descriptions  of  each  feature  required  by  the  TCSEC  and 
explanations  of  the  commands  that  make  those  features  available  to  users.  A  task- 
oriented  presentation  is  the  more  common  approach  taken  in  most  user  manuals, 
since  it  is  oriented  towards  the  specific  actions  that  are  necessary  to  enter  a  system 
and  start  working.  Such  a  presentation  will  often  take  the  form  of  a  tutorial  that 
describes  the  interactions  that  a  user  will  usually  have  with  the  system,  e.g.,  logging 
on,  setting  file  access,  changing  the  password,  etc. 

2.3  CONTENT 

Because  this  guideline  is  devoted  to  explaining  a  TCSEC  requirement,  it  will 
consider  the  content  of  a  SFUG  only  from  the  perspective  of  the  features  required 
by  the  TCSEC  that  should  be  documented  in  the  SFUG.  Other  security-relevant 
features  not  addressed  by  the  TCSEC  (e.g.,  object  downgrading  or  network 
commands)  might  also  be  included  in  the  SFUG,  but  will  not  be  discussed  in  this 
guideline. 

The  remainder  of  this  section  will  list  the  features  required  by  the  TCSEC, 
identify  the  specific  requirements  that  define  them,  and  discuss  how  they  apply  to 
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the  SFUG.  Many  of  the  requirements  cited  use  the  acronym  TCB,  which  expands  to 
Trusted  Computing  Base.  As  defined  in  the  TCSEC,  the  TCB  is: 

“The  totality  of  protection  mechanisms  within  a  computer 
system  --  including  hardware,  firmware,  and  software  --  the 
combination  of  which  is  responsible  for  enforcing  a  security 
policy.  A  TCB  consists  of  one  or  more  components  that 
together  enforce  a  unified  security  policy  over  a  product  or 
system.  The  ability  of  a  TCB  to  correctly  enforce  a  security 
policy  depends  solely  on  the  mechanisms  within  the  TCB  and 
on  the  correct  input  by  system  administrative  personnel  of 
parameters  (e.g.,  a  user’s  clearance)  related  to  the  security 
policy.”  [TCSEC,  p.  116] 

2.3.1  TECHNICAL  SECURITY  POLICY 

The  technical  security  policy  is  the  description  of  the  access  control  model 
that  the  system  enforces.  This  description  can  be  either  informal  or  formal  for 
classes  Cl  through  B1,  but  classes  B2  to  A1  must  have  a  formal  description.  The 
TCSEC  design  documentation  requirement  mandates  that  the  informal  description 
exist  for  all  criteria  classes  where  it  states: 

“Documentation  shall  be  available  that  provides  a  description 
of  the  manufacturer’s  philosophy  of  protection  .  .  .”  [x.x.4.4] 

Starting  at  B1,  the  design  specification  and  verification  requirement 
strengthens  this  notion  of  a  technical  security  policy  with  the  explicit  requirement 
that: 


“An  informal  or  formal  model  of  the  security  policy  supported 
by  the  TCB  shall  be  maintained  over  the  life  cycle  of  the  ADP 
system  and  demonstrated  to  be  consistent  with  its  axioms.” 

[x.x. 3.2.2] 

At  class  B2,  the  design  specification  and  verification  requirement  is  changed 
to  mandate  a  formal  technical  security  policy  model.  Classes  B3  and  A1  incorporate 
new  requirements  for  additional  supporting  documentation  that  makes  it  possible  to 
trace  the  basis  for  each  feature  in  the  system  from  the  technical  security  policy  to 
the  implementation. 

In  the  context  of  the  TCSEC,  neither  the  philosophy  of  protection  nor  the 
formal  model  have  to  be  available  to  the  user;  however,  the  fact  that  the  features  of 
the  system  flow  from  these  fundamental  statements  makes  either  one  an 
appropriate  starting  point  for  describing  how  the  system  works.  The  philosophy  of 
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protection  is  probably  the  better  choice  for  the  SFUG,  since  it  is  usually  written  in  a 
more  intuitive  style  than  a  precisely  stated  security  policy  statement.  In  either  case, 
the  technical  policy  would  be  presented  early  in  the  SFUG  to  provide  the  overall 
context  for  the  rest  of  the  discussion,  effectively  becoming  the  thesis  for  the  SFUG. 

2.3.2  IDENTIFICATION  AND  AUTHENTICATION 

The  single  largest  and  most  crucial  section  of  the  SFUG,  both  from  the 
perspective  of  the  TCSEC  and  of  overall  system  documentation,  is  the  section  that 
discusses  how  users  identify  and  authenticate  themselves  (i.e.,  logon)  to  the 
system.  The  process  of  identification  and  authentication  (l&A)  defines  the  identity  of 
the  subject  that  the  TCB  creates  to  act  on  the  user’s  behalf.  For  division  B  and  A 
multilevel  systems,  the  l&A  process  defines  the  upper  and  lower  bounds  on  the 
security  level  of  the  subject  as  well.  All  subsequent  access  control  decisions 
depend  on  this  information  being  correct.  The  SFUG  should  therefore  be  very 
specific  in  describing  both  the  l&A  procedures  and  the  user’s  responsibilities  for 
protecting  any  information  that  is  expected  to  be  kept  secret  (e.g.,  passwords  or 
personal  identification  numbers). 


The  TCSEC  requirement  for  division  C  computer  systems  is  shown  below, 
with  bold  type  showing  the  C2  requirements  that  go  beyond  those  at  C1 . 

“The  TCB  shall  require  users  to  identify  themselves  to  it  before 
beginning  to  perform  any  other  actions  that  the  TCB  is 
expected  to  mediate.  Furthermore,  the  TCB  shall  use  a 
protected  mechanism  (e.g.,  passwords)  to  authenticate  the 
user’s  identity.  The  TCB  shall  protect  authentication  data  so 
that  it  cannot  be  accessed  by  any  unauthorized  user.  The 
TCB  shall  be  able  to  enforce  individual  accountability  by 
providing  the  capability  to  uniquely  identify  each  individual 
ADP  system  user.  The  TCB  shall  also  provide  the 
capability  of  associating  this  identity  with  all  auditable 
actions  taken  by  that  individual.  ”  [2. 2. 2.1] 

Based  on  this  requirement,  the  SFUG  for  a  division  C  system  should  describe 
the  identification  process,  including  the  use  of  a  protected  authentication 
mechanism.  To  complement  the  protection  that  the  TCB  must  give  the 
authentication  data,  the  SFUG  should  make  it  clear  that  the  user  must  protect  the 
data  too,  for  example,  by  not  sharing  a  password  with  other  users  or  writing  it  down 
on  a  sheet  of  paper  next  to  the  terminal. 
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For  divisions  B  and  A,  the  addition  of  multiple  security  levels  changes  the 
requirement,  primarily  by  requiring  the  use  of  a  user’s  clearance  as  a  bound  on  the 
security  label  of  any  subject  that  the  TCB  creates  for  that  user.  The  B1  requirement, 
which  does  not  change  for  the  higher  classes,  is  shown  below,  with  bold  type 
showing  additional  wording  and  struck-out  type  showing  wording  that  was  deleted. 

“The  TCB  shall  require  users  to  identify  themselves  to  it  before 
beginning  to  perform  any  other  actions  that  the  TCB  is 
expected  to  mediate.  Furthermore,  the  TCB  shall  use  a 
protected  mechanism  maintain  authentication  data  that 
includes  information  for  verifying  the  identity  of  individual 
users  (e.g.,  passwords)  as  well  as  information  for 
determining  the  clearance  and  authorizations  of  individual 
users.  This  data  shall  be  used  by  the  TCB  to  authenticate 
the  user’s  identity  and  to  ensure  that  the  security  level  and 
authorization  of  subjects  external  to  the  TCB  that  may  be 
created  to  act  on  behalf  of  the  individual  user  are 
dominated  by  the  clearance  and  authorization  of  that  user. 

The  TCB  shall  protect  authentication  data  so  that  it  cannot  be 
accessed  by  any  unauthorized  user.  The  TCB  shall  be  able  to 
enforce  individual  accountability  by  providing  the  capability  to 
uniquely  identify  each  individual  ADP  system  user.  The  TCB 
shall  also  provide  the  capability  of  associating  this  identity  with 
all  auditable  actions  taken  by  that  individual.”  [3. 1.2.1] 

For  all  division  B  and  A  systems,  the  SFUG  should  incorporate  a  discussion 
of  the  relationship  between  a  user’s  clearance  (i.e.,  his  or  her  general  authorization 
to  see  information  of  a  particular  sensitivity— whether  or  not  it  is  electronic)  and  the 
security  level  that  the  TCB  associates  with  a  particular  subject  (e.g.,  computer 
process  or  interactive  session)  that  is  acting  on  that  user’s  behalf.  Additionally,  the 
practical  consideration  of  how  to  establish  the  security  level  of  that  subject,  for 
example,  by  using  a  logon  option  or  a  specific  terminal,  should  be  explained  in  the 
SFUG. 


Starting  at  B2,  there  is  an  additional  requirement  for  a  trusted  path  to 
strengthen  the  confidence  of  both  the  user  and  the  TCB  that  the  l&A  process  is 
happening  correctly.  This  requirement  is  shown  below  in  both  the  B2  and  B3/A1 
forms. 


“The  TCB  shall  support  a  trusted  communication  path  between 
itself  and  user  for  initial  login  and  authentication. 
Communications  via  this  path  shall  be  initiated  exclusively  by  a 
user.”  [3.2.2.1.1  (B2)] 
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“The  TCB  shall  support  a  trusted  communication  path  between 
itself  and  ttser  users  for  initial  login  and  authentication,  use 
when  a  positive  TCB-to-user  connection  is  required  (e.g., 
login,  change  subject  security  level).  Communications  via 
this  trusted  path  shall  be  initiated  activated  exclusively  by  a 
user  or  the  TCB  and  shall  be  logically  Isolated  and 
unmistakably  distinguishable  from  other  paths.”  [3. 3.2. 1.1 
(B3/A1)] 

Trusted  path  is  useless  if  it  is  not  used;  therefore,  the  SFUG  should  be  written 
so  that  the  user  understands  how  to  initiate  the  trusted  path,  especially  at  logon,  and 
why  it  is  important  to  do  so.  For  systems  that  satisfy  the  B3  trusted  path 
requirement,  the  SFUG  should  also  explain  how  the  initiation  of  a  trusted  path  during 
a  session,  whether  by  the  user  or  the  TCB,  affects  the  currently  running  subject,  as 
well  as  how  to  recognize  the  trusted  path. 

2.3.3  DISCRETIONARY  ACCESS  CONTROL  FACILITY 

The  discretionary  access  control  (DAC)  facility  provides  the  mechanism  by 
which  the  individual  user  can  control  access  to  his  or  her  data.  Some  form  of  DAC 
is  required  for  every  class  of  the  TCSEC.  After  the  procedures  for  identifying  and 
authenticating  themselves  to  the  system,  the  DAC  facilities  will  be  the  aspects  of  the 
system  security  of  most  interest  to  most  users. 

The  DAC  facility  is  first  defined  by  the  Cl  DAC  requirement  that: 

“The  TCB  shall  define  and  control  access  between  named 
users  and  named  objects  (e.g.,  files  and  programs)  in  the  ADP 
system.  The  enforcement  mechanism  (e.g.,  self/group/public 
controls,  access  control  lists)  shall  allow  users  to  specify  and 
control  sharing  of  those  objects  by  named  individuals  or 
defined  groups  or  both.”  [2. 1.1.1] 

At  C2  this  requirement  is  enhanced  to  read  (bold  type  shows  added  words): 

“The  TCB  shall  define  and  control  access  between  named 
users  and  named  objects  (e.g.,  files  and  programs)  in  the  ADP 
system.  The  enforcement  mechanism  (e.g.,  self/group/public 
controls,  access  control  lists)  shall  allow  users  to  specify  and 
control  sharing  of  those  objects  by  named  individuals,  or 
defined  groups  of  individuals,  or  by  both,  and  shall  provide 
controls  to  limit  propagation  of  access  rights.  The 
discretionary  access  control  mechanism  shall,  either  by 
explicit  user  action  or  by  default,  provide  that  objects  are 
protected  from  unauthorized  access.  These  access 
controls  shall  be  capable  of  including  or  excluding  access 
to  the  granularity  of  a  single  user.  Access  permission  to 
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an  object  by  users  not  already  possessing  access 
permission  shall  only  be  assigned  by  authorized  users.” 

[2.2. 1.1] 

After  this  it  remains  the  same  until  B3,  when  it  is  changed  to  read  (bold  type 
shows  added  words,  struck-out  type  shows  deleted  words): 

“The  TCB  shall  define  and  control  access  between  named 
users  and  named  objects  (e.g.,  files  and  programs)  in  the  ADP 
system.  The  enforcement  mechanism  (e.g.,  self/group/pubfte 
contreter  access  control  lists)  shall  allow  users  to  specify  and 
control  sharing  of  those  objects  by  named  individuals, ;  or 
defined  groups— of  individuals,  or  by  both,  and  shall  provide 
controls  to  limit  propagation  of  access  rights.  The  discretionary 
access  control  mechanism  shall,  either  by  explicit  user  action 
or  by  default,  provide  that  objects  are  protected  from 
unauthorized  access.  These  access  controls  shall  be  capable 
of  specifying,  for  each  named  object,  a  list  of  named 
individuals  and  a  list  of  groups  of  named  individuals  with 
their  respective  modes  of  access  to  that  object. 
Furthermore,  for  each  such  named  object,  it  shall  be 
possible  to  specify  a  list  of  named  individuals  and  a  list  of 
groups  of  named  individuals  for  which  no  access  to  the 
object  is  to  be  given,  including  or  excluding  access  to  the 
granularity  of  a  single  user:  Access  permission  to  an  object  by 
users  not  already  possessing  access  permission  shall  only  be 
assigned  by  authorized  users.”  [3.3. 1.1] 


For  any  version  of  this  requirement,  the  goal  for  the  SFUG  author  is  the 
same— to  describe  to  users  how  to  use  the  DAC  enforcement  mechanism  to  control 
access  to  the  objects  that  they  own.  The  SFUG  should  provide  enough  information 
for  the  user  to  understand  what  a  named  object,  a  named  user,  and  a  group  are,  as 
well  as  what  types  of  objects  can  be  controlled  with  DAC.  It  should  also  explain 
how  a  new  user  or  group  is  defined  to  the  system.  The  SFUG  should  also  describe 
the  process  by  which  access  rights  are  initially  determined  and  then  propagated. 
Finally,  the  SFUG  should  describe  the  system  commands  and  procedures  for  using 
the  DAC  facility. 

2.3.4  ELECTRONIC  LABELS 

The  distinguishing  feature  of  all  division  B  and  A  computer  classes  is  the 
electronic  label.  An  electronic  label  is  an  attribute  of  each  subject  and  object  under 
TCB  control  that  indicates  the  sensitivity  of  the  information  that  a  subject  is 
authorized  to  see  or  that  is  contained  in  an  object.  The  real  world  equivalents  of 
these  concepts  are  security  clearances  and  classification  markings.  Many  users 
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who  are  familiar  with  these  real  world  examples  have  trouble  adapting  to  electronic 
labels;  therefore,  the  SFUG  written  for  a  multilevel  system  should  discuss  labels  and 
their  effect  on  a  user’s  actions. 

The  basic  label  requirement  is  defined  by  the  following  words  at  B1: 

“Sensitivity  labels  associated  with  each  subject  and  storage 
object  under  its  control  (e.g.,  process,  file,  segment,  device) 
shall  be  maintained  by  the  TCB.  These  labels  shall  be  used  as 
the  basis  for  mandatory  access  control  decisions.  In  order  to 
import  non-labeled  data,  the  TCB  shall  request  and  receive 
from  an  authorized  user  the  security  level  of  the  data,  and  all 
such  actions  shall  be  auditable  by  the  TCB.”  [3. 1.1. 3] 

At  B2,  the  first  sentence  is  changed  to  read: 

“Sensitivity  labels  associated  with  each  ADP  system  resource 
(e.g.,  subject,  storage  object,  ROM)  that  is  directly  or  indirectly 
accessible  by  subjects  external  to  the  TCB  shall  be  maintained 
by  the  TCB.”  [3.2.1. 3] 

This  reflects  the  general  B2  through  A1  requirement  that  all  computer 
resources  be  under  the  control  of  the  TCB. 

Another  label-related  requirement  that  affects  the  users  of  a  system  is  the 
one  for  labeling  human-readable  output,  which  states  that: 

“The  ADP  system  administrator  shall  be  able  to  specify  the 
printable  label  names  associated  with  exported  sensitivity 
labels.  The  TCB  shall  mark  the  beginning  and  end  of  all 
human-readable,  paged,  hardcopy  output  (e.g.,  line  printer 
output)  with  human-readable  sensitivity  labels  that  properly 
represent  the  sensitivity  of  the  output.  The  TCB  shall,  by 
default,  mark  the  top  and  bottom  of  each  page  of  human- 
readable,  paged,  hardcopy  output  (e.g.,  line  printer  output)  with 
human-readable  sensitivity  labels  that  properly  represent  the 
overall  sensitivity  of  the  output  or  that  properly  represent  the 
sensitivity  of  the  information  on  the  page.  The  TCB  shall,  by 
default  and  in  an  appropriate  manner,  mark  other  forms  of 
human-readable  output  (e.g.,  maps,  graphics)  with  human- 
readable  sensitivity  labels  that  properly  represent  the  sensitivity 
of  the  output.  Any  override  of  these  marking  defaults  shall  be 
auditable  by  the  TCB."  [3.1 .1 .3.2.3] 

The  above  requirement  is  the  same  for  classes  B1  through  A1 . 
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These  two  requirements,  for  subject  sensitivity  labels  and  labeled  human- 
readable  output,  apply  to  any  multilevel  system;  therefore,  the  SFUG  for  all  B  and  A 
level  systems  should,  at  the  least,  explain: 

•  How  labels  are  attached  to  subjects  and  objects, 

•  The  relationship  between  the  “clearance”  that  a  user  has  and  the  label 
that  is  associated  with  a  particular  computer  session,  and 

•  The  reason  for  job  and  page  labels  on  printed  output  and  terminal  or 
window  labels  on  computer  displays  (as  well  as  cautions  about  disabling 
the  display  of  such  labels). 

The  last  requirement  that  affects  users  is  one  for  subject  sensitivity  labels  that 
requires  that: 

“The  TCB  shall  immediately  notify  a  terminal  user  of  each 
change  in  the  security  level  associated  with  that  user  during  an 
interactive  session.  A  terminal  user  shall  be  able  to  query  the 
TCB  as  desired  for  a  display  of  the  subject’s  complete 
sensitivity  label.”  [3.2. 1.3.3] 

The  above  requirement  applies  to  classes  B2  through  A1;  therefore,  the 
SFUG  for  these  systems  should  explain  the  mechanism  used  to  notify  a  user  of  a 
security  level  change. 

2.3.5  MANDATORY  ACCESS  CONTROL  FACILITY 

Closely  associated  with,  but  separate  from,  the  requirement  for  labels  is  the 
requirement  for  mandatory  access  control  (MAC).  MAC  refers  to  the  set  of  rules 
that  control  a  subject’s  access  to  an  object  based  on  the  label  attached  to  each. 

The  MAC  facility  is  first  defined  by  the  B1  MAC  requirement  that: 

“The  TCB  shall  enforce  a  mandatory  access  control  policy  over 
all  subjects  and  storage  objects  under  its  control  (e.g., 
processes,  files,  segments,  devices).  These  subjects  and 
objects  shall  be  assigned  sensitivity  labels  that  are  a 
combination  of  hierarchical  classification  levels  and  non- 
hierarchical  categories,  and  the  labels  shall  be  used  as  the 
basis  for  mandatory  access  control  decisions.  The  TCB  shall 
be  able  to  support  two  or  more  such  security  levels.  The 
following  requirements  shall  hold  for  all  accesses  between 
subjects  and  objects  controlled  by  the  TCB:  A  subject  can  read 
an  object  only  if  the  hierarchical  classification  in  the  subject’s 
security  level  is  greater  than  or  equal  to  the  hierarchical 
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classification  in  the  object’s  security  level  and  the  non- 
hierarchical  categories  in  the  subject’s  security  level  include  all 
the  non-hierarchical  categories  in  the  object’s  security  level.  A 
subject  can  write  an  object  only  if  the  hierarchical  classification 
in  the  subject’s  security  level  is  less  than  or  equal  to  the 
hierarchical  classification  in  the  object’s  security  level  and  all 
the  non-hierarchical  categories  in  the  subject’s  security  level 
are  included  in  the  non-hierarchical  categories  in  the  object’s 
security  level.  Identification  and  authentication  data  shall  be 
used  by  the  TCB  to  authenticate  the  user’s  identity  and  to 
ensure  that  the  security  level  and  authorization  of  subjects 
external  to  the  TCB  that  may  be  created  to  act  on  behalf  of  the 
individual  user  are  dominated  by  the  clearance  and 
authorization  of  that  user.”  [3. 1.1. 4] 

For  classes  B2  through  A1,  the  requirement  is  enhanced  to  reflect  the 
pervasive  TCB  control  required  by  these  higher  classes.  (The  bold  type  in  the 
following  quote  shows  the  additional  wording,  while  the  struck-out  type  shows  the 
phases  deleted.) 

“The  TCB  shall  enforce  a  mandatory  access  control  policy  over 

all  sotojeets- . -and . -etofage- . ebjects  under  its . eofitrol  (e.g.,- 

proeeseee,- -files-,  -segfnefitei-devteee)-  resources  (i.e.,  subjects, 
storage  objects,  and  I/O  devices)  that  are  directly  or 
indirectly  accessible  by  subjects  external  to  the  TCB. 

These  subjects  and  objects  shall  be  assigned  sensitivity  labels 
that  are  a  combination  of  hierarchical  classification  levels  and 
non-hierarchical  categories,  and  the  labels  shall  be  used  as  the 
basis  for  mandatory  access  control  decisions.  The  TCB  shall 
be  able  to  support  two  or  more  such  security  levels.  The 
following  requirements  shall  hold  for  all  accesses  between 
subjects  and  objects  controlled  by  the -  TCB:  all  subjects 
external  to  the  TCB  and  all  objects  directly  or  indirectly 
accessible  by  these  subjects:  A  subject  can  read  an  object 
only  if  the  hierarchical  classification  in  the  subject’s  security 
level  is  greater  than  or  equal  to  the  hierarchical  classification  in 
the  object’s  security  level  and  the  non-hierarchical  categories 
in  the  subject’s  security  level  include  all  the  non-hierarchical 
categories  in  the  object’s  security  level.  A  subject  can  write  an 
object  only  if  the  hierarchical  classification  in  the  subject’s 
security  level  is  less  than  or  equal  to  the  hierarchical 
classification  in  the  object’s  security  level  and  all  the  non- 
hierarchical  categories  in  the  subject’s  security  level  are 
included  in  the  non-hierarchical  categories  in  the  object’s 
security  level.  Identification  and  authentication  data  shall  be 
used  by  the  TCB  to  authenticate  the  user’s  identity  and  to 
ensure  that  the  security  level  and  authorization  of  subjects 
external  to  the  TCB  that  may  be  created  to  act  on  behalf  of  the 
individual  user  are  dominated  by  the  clearance  and 
authorization  of  that  user.”  [3. 2. 1.4] 
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Because  the  TCB,  rather  than  the  user,  controls  the  actual  interaction 
between  the  labels  of  subjects  and  objects,  the  SFUG  only  needs  to  explain  to 
users  how  MAC  constrains  their  actions.  This  discussion  is  probably  most  natural 
under  the  section  that  addresses  the  technical  security  policy.  In  most  cases,  a 
user  can  have  only  one  effect  on  the  MAC  policy— to  change  the  label  for  a  session, 
which  is  already  described  under  either  the  discussion  of  identification  and 
authentication  or  labels. 

2.3.6  TRUSTED  FACILITY  MANAGEMENT 

Beginning  at  B2,  there  is  a  TCSEC  requirement  that: 

“The  TCB  shall  support  separate  operator  and  administrator 
functions.”  [3.2.3. 1 .4] 

This  mandates  a  separation  of  duties  in  the  administration  of  computer 
systems  that  are  supposed  to  be  protecting  information.  This  corresponds  to  the 
natural  separation  of  duties  found  in  most  human  activity.  Although  this  is  not  a 
requirement  until  B2,  many  sites  that  are  concerned  about  security  are  instituting 
programs  where  the  responsibility  for  security  administration  of  the  computer  system 
is  centralized  in  a  person  with  the  title  of  computer,  or  information  system,  security 
officer  (CSO  or  ISSO,  respectively).  Whether  the  computer  system  being  described 
in  the  SFUG  satisfies  the  trusted  facility  management  requirement  or  not,  the  author 
of  the  SFUG  for  that  system  may  want  to  postulate  the  existence  of  such  a  position 
to  represent  the  entity  that  is  responsible  for  security  issues  that  are  outside  the 
control  of  the  users.  This  both  allows  the  SFUG  to  be  written  in  a  more  active  voice 
and  simplifies  the  job  of  conveying  distinctions  between  user  security  responsibilities 
and  site  management  security  responsibilities. 


14 


3.  EXAMPLES  OF  SFUG  PRESENTATION  STYLES 


This  chapter  presents  two  sample  stand-alone  SFUGs  to  show  what  could  go 
into  a  SFUG  and  possibly  give  the  reader  some  ideas  for  organizing  a  system 
specific  SFUG.  The  actual  contents  and  organization  of  a  real  SFUG  will  be 
different  to  reflect  the  specific  mechanisms  of  the  individual  system  and  the 
organization  of  the  rest  of  the  system  documentation.  The  first  example  uses  a 
feature-oriented  style  presentation,  while  the  second  shows  a  task-oriented  style. 

In  addition  to  these  generic  examples,  the  reader  may  find  it  helpful  to  review 
the  SFUGs  of  previously  evaluated  systems  to  see  what  worked  for  them.  Entries  2 
through  16  in  the  bibliography  list  the  Final  Evaluation  Reports  (FERs)  for  products 
on  the  Evaluated  Products  List  that  had  published  FERs  at  the  time  this  guideline 
was  printed.  Each  entry  is  annotated  with  the  document(s)  identified  in  the  FER  as 
satisfying  the  SFUG  requirement  for  that  product. 
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THE  FEATURE-ORIENTED  SFUG 

At  a  high  level,  the  feature-oriented  example  SFUG  is  arranged  in  the  following 
fashion: 

1.  INTRODUCTION  TO  THE  SFUG 

2.  SYSTEM  SECURITY  OVERVIEW 

2.1  SYSTEM  PHILOSOPHY  OF  PROTECTION 

2.2  DEFINITION  OF  TERMS  AND  SERVICES 

2.3  THE  INFORMATION  SYSTEM  SECURITY  OFFICER 

2.4  USER  SECURITY  RESPONSIBILITIES 

3.  SECURITY-RELATED  COMMANDS  FOR  USERS 

3.1  USER  IDENTIFICATION  AND  AUTHENTICATION 

3.1.1  Trusted  Path 

3.1.2  Logging  On  to  the  System 

3.1.3  Password  Considerations 

3.1.4  Changing  Group  Membership 

3.1.5  Changing  Current  MAC  Authorizations 

3.1.6  Logging  Off  of  the  System 

3.1.7  l&A  Errors  and  Their  Causes 

3.2  DISCRETIONARY  ACCESS  CONTROL  FACILITIES 

3.2.1  Setting  DAC  on  Named  Objects 

3.2.2  Default  DAC  Protection 

3.2.3  DAC  Groups 

3.2.4  DAC  Errors  and  Their  Causes 

3.3  MANDATORY  ACCESS  CONTROL  FACILITIES 

3.3.1  Printing  Labeled  Objects 

3.3.2  Accessing  Single-Level  Devices 

3.3.3  Accessing  Multilevel  Devices 

3.3.4  Downgrading  Labeled  Objects 

3.3.5  MAC  Errors  and  Their  Causes 

3.4  OBJECT  MANIPULATION  FACILITIES 

3.4.1  Object  Creation,  Reuse,  and  Deletion 

3.4.2  Importing  Machine-Readable  Objects 

3.4.3  Exporting  Machine-Readable  Objects 

3.4.4  Determining  the  Properties  of  Objects 

3.4.5  Object  Manipulation  Errors  and  Their  Causes 

The  annotated  outline  follows. 
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EXAMPLES  OF  SFUG  PRESENTATION  STYLES 


1.  INTRODUCTION  TO  THE  SFUG 

This  part  of  the  SFUG  should  identify  what  the  SFUG  is,  who  it  is  written  for, 
what  it  will  cover,  and  where  to  go  for  more  information,  if  needed. 

2.  SYSTEM  SECURITY  OVERVIEW 

This  section  provides  the  background  on  the  overall  operation  of  the  security 
controls  in  the  system  so  that  users  can  then  understand  the  options  and  actions  of 
individual  security-relevant  commands. 

2.1  SYSTEM  PHILOSOPHY  OF  PROTECTION 

This  section  should  describe  the  general  environment  for  which  the  system  is 
designed  and  briefly  explain  how  this  environment  motivates  the  approach  to 
protecting  information  stored  in  the  system.  The  purpose  of  this  section  is  to  lay  the 
foundation  for  the  user’s  understanding  of  the  system’s  security  features,  with  later 
sections  detailing  what  specific  security  services  are  available  and  when  and  how  to 
use  them. 

2.2  DEFINITION  OF  TERMS  AND  SERVICES 

This  section  should  first  introduce  the  terms  that  will  be  used  to  describe  the 
security  services  available  in  the  system  and  then  proceed  to  introduce  those 
services,  without  detailing  exactly  how  they  are  used.  Recommended  topics  for  this 
section  are: 

•  An  explanation  of  the  general  concepts  of  subjects  and  objects,  followed 
by  the  identification  of  the  subjects  and  objects  in  the  system. 

•  An  explanation  of  object  reuse  and  its  role  in  protecting  information  in  the 
system. 


•  An  explanation  of  the  components  of  the  l&A  (identification  and 
authentication)  process  (e.g.,  user-id,  password,  or  smartcard)  in  the  system  and  the 
importance  of  l&A  to  system  security. 
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•  An  explanation  of  DAC,  groups,  privileges,  protection  bits/ACLs,  and  any 
other  terms  and  concepts  related  to  the  system’s  DAC  policy,  followed  by  a 
description  of  how  the  DAC  policy  applies  to  the  system  subjects  and  objects. 

•  An  explanation  of  MAC,  security  labels,  sensitivity  levels,  categories, 
authorizations,  and  any  other  terms  and  concepts  related  to  the  system’s  MAC 
policy,  followed  by  a  description  of  how  the  MAC  policy  applies  to  the  system 
subjects  and  objects. 

2.3  THE  INFORMATION  SYSTEM  SECURITY  OFFICER 

This  section  discusses  the  role  of  the  Information  System  Security  Officer 
(ISSO)  in  maintaining  the  security  of  the  system.  It  can  also  explain  which  problems 
should  be  reported  to  the  ISSO  and  which  should  be  reported  to  the  system 
administrator  (if  the  roles  are  separate).  If  the  format  of  the  SFUG  allows  it,  this 
section  could  have  space  for  site-specific  notes  on  the  ISSO/user  relationship. 

2.4  USER  SECURITY  RESPONSIBILITIES 

This  section  discusses  the  user’s  responsibilities  with  respect  to  properly 
using  the  system  security  features.  This  would  optimally  be  a  tutorial  that  teaches 
effective  use  of  the  system  security  services,  but  any  presentation  that  relates  the 
security  services  to  the  user’s  day-to-day  use  of  the  system  is  appropriate.  Some 
issues  that  might  be  addressed  are: 

•  Authentication  token  (e.g.,  password  or  smartcard)  protection. 

•  Warnings  about  leaving  a  terminal  unattended. 

•  Procedures  for  “locking”  a  process  when  the  terminal  must  be  left 
unattended,  but  logged  in. 

•  Default  DAC  access  for  named  objects  (e.g.,  files  and  directories). 

•  Cautions  about  using  programs  that  are  not  part  of  the  standard  system 
configuration  (e.g.,  utilities  or  applications  that  have  not  been  reviewed  and  tested 
by  the  system  administrator(s)). 

•  Cautions  about  the  effect  of  network  access  on  system  and  data  security. 
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3.  SECURITY-RELATED  COMMANDS  FOR  USERS 

This  section  comprises  the  majority  of  the  SFUG  since  it  describes  in  detail 
the  commands  and  procedures  for  actually  using  the  system. 

3.1  USER  IDENTIFICATION  AND  AUTHENTICATION 

This  section  should  step  through  the  procedures  for  logging  on  to  and  off  of 
the  system  and  for  manipulating  privileges  and  participation  in  the  system. 
Additionally,  any  of  the  errors  that  might  occur  during  the  use  of  these  commands 
and  the  corrective  actions  should  be  described  here. 

3.1.1  Trusted  Path 

In  B2  and  above  systems,  the  first  thing  that  a  user  will  have  to  do  to  logon  is 
establish  a  trusted  path  between  his  terminal  and  the  system  TCB.  This  section 
should  describe  that  process.  For  B3  and  A1  systems,  this  trusted  path  is  available 
for  any  direct  interaction  between  the  TCB  and  the  user;  therefore,  in-session 
invocation  of  the  trusted  path  and  its  effects  on  currently  executing  processes 
should  be  described  here. 

3.1.2  Logging  On  to  the  System 

The  procedure  for  logging  on  to  the  system  should  be  described.  If  the 
system  has  MAC,  the  procedures  for  logging  on  with  specific,  non-default 
authorizations  should  be  described. 

3.1.3  Password  Considerations 

The  procedures  and  commands  for  setting,  changing,  and  protecting 
passwords  should  be  described. 

3.1.4  Changing  Group  Membership 

In  systems  with  the  concept  of  DAC  groups,  the  mechanisms  for  users  to 
specify  the  group  membership(s)  that  should  be  used  in  making  DAC  access 
decisions  (if  such  capability  is  present)  should  be  described. 
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3.1.5  Changing  Current  MAC  Authorizations 

In  systems  with  MAC,  if  the  user  can  change  their  current  authorization  level 
and  category  set  without  logging  off,  the  mechanism  and  procedure  should  be 
described. 

3.1.6  Logging  Off  of  the  System 

The  command  or  procedure  for  logging  off  the  system  should  be  described. 

3.1.7  l&A  Errors  and  Their  Causes 

The  possible  error  messages  that  can  occur  when  l&A  commands  are 
improperly  invoked  should  be  noted  and  the  correct  or  expected  inputs  should  be 
explained. 

3.2  DISCRETIONARY  ACCESS  CONTROL  FACILITIES 

This  section  should  describe  the  DAC-related  commands  and  procedures  for 
the  system.  This  section  will  be  present  in  some  form  at  all  levels  of  the  criteria. 

3.2.1  Setting  DAC  on  Named  Objects 

This  section  should  describe  how  users  can  set  the  discretionary  access 
permissions,  and  what  the  permissions  mean,  for  the  different  types  of  named 
objects  in  the  system. 

3.2.2  Default  DAC  Protection 

The  means  for  determining  and  setting  the  default  discretionary  access 
controls  on  user  controlled  or  owned  named  objects  should  be  described. 

3.2.3  DAC  Groups 

When  the  capability  exists  for  users  to  define  groups  of  users  for  the  purpose 
of  DAC,  the  mechanisms  for  defining  these  groups  should  be  described. 
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3.2.4  DAC  Errors  and  Their  Causes 

The  possible  error  messages  that  can  occur  when  DAC  commands  are 
improperly  invoked  should  be  noted  and  the  correct  or  expected  inputs  should  be 
explained. 

3.3  MANDATORY  ACCESS  CONTROL  FACILITIES 

This  section  is  for  systems  in  the  B  and  A  classes.  It  describes  the 
commands  that  a  general  user  will  need  for  dealing  with  labeled  objects. 

3.3.1  Printing  Labeled  Objects 

This  section  describes  the  mechanism  for  printing  or  otherwise  producing 
non-electronic  versions  of  labeled  objects.  Of  specific  interest  is  the  mechanism 
that  would  be  used  for  overriding  the  default  printing  of  the  object’s  label  in  human- 
readable  form.  The  description  of  this  capability  could  be  accompanied  by  a 
discussion  of  the  security  considerations  that  go  with  its  use. 

3.3.2  Accessing  Single-Level  Devices 

This  section  should  discuss  the  constraints  on  the  use  of  single-level  devices 
in  the  presence  of  multiple  authorization  levels.  For  example,  this  section  could 
discuss  how  the  TCB  determines  a  user’s  access  to  a  single-level  device  based  on 
the  user’s  authorization  level. 

3.3.3  Accessing  Muitiievel  Devices 

This  section  should  discuss  the  rules  for  the  interaction  between  users  at 
multiple  authorization  levels  and  multilevel  devices. 

3.3.4  Downgrading  Labeled  Objects 

Although  it  is  not  a  part  of  TCSEC  evaluations,  if  the  system  offers  an  object 
downgrade  facility  that  is  available  to  the  target  audience  of  the  SFUG,  this  facility 
and  cautions  on  its  proper  use  should  be  described. 
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3.3.5  MAC  Errors  and  Their  Causes 

The  possible  error  messages  that  can  occur  when  MAC  commands  are 
improperly  invoked  should  be  noted  and  the  correct  or  expected  inputs  should  be 
explained. 

3.4.  OBJECT  MANIPULATION  FACILITIES 

This  section  should  discuss  the  commands  and  mechanisms  available  for 
dealing  with  objects. 

3.4.1  Object  Creation,  Reuse,  and  Deletion 

This  section  should  discuss  how  the  system  creates,  reuses,  and  deletes 
user  visible  objects.  Any  commands  which  allow  the  creation  of  user  owned  objects 
(e.g.,  mailboxes  or  blank  files)  should  be  described.  The  information  on  object 
reuse  should  be  for  informational  purposes  only,  since  all  C2  and  above  systems 
are  required  to  do  object  reuse  without  user  intervention.  For  systems  with  MAC, 
this  section  should  describe  how  sensitivity  labels  and  discretionary  access  lists  are 
assigned  to  an  object. 

3.4.2  Importing  Machine-Readable  Objects 

The  mechanisms  for  a  user  to  introduce  a  machine-readable  object  into  the 
system  from  an  external  source  {e.g.,  tape,  removable  diskette,  or  network)  and 
assign  discretionary  and  mandatory  access  control  properties  to  it  should  be 
described  if  such  a  facility  exists. 

3.4.3  Exporting  Machine-Readable  Objects 

The  mechanisms  for  a  user  to  export  a  machine  readable  object  from  the 
system  to  an  external  source  (e.g.,  tape,  removable  diskette,  or  network),  along  with 
its  discretionary  and  mandatory  access  control  properties,  should  be  described  if 
such  a  facility  exists. 

3.4.4  Determining  the  Properties  of  Objects 

The  commands  or  mechanisms  for  determining  the  discretionary  and 
mandatory  access  control  properties  of  an  object  should  be  described. 
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3.4.5  Object  Manipulation  Errors  and  Their  Causes 

The  possible  error  messages  that  can  occur  when  object  manipulation 
commands  are  improperly  invoked  should  be  noted  and  the  correct  or  expected 
inputs  should  be  explained. 


23 


A  GUIDE  TO  WRITING  THE  SFUG 


THE  TASK-ORIENTED  SFUG 

At  a  high  level,  the  task-oriented  example  SFUG  is  arranged  in  the  following  fashion 

1.  INTRODUCTION  TO  THE  SFUG 

2.  SYSTEM  SECURITY  OVERVIEW 

2.1  SYSTEM  PHILOSOPHY  OF  PROTECTION 

2.2  DEFINITION  OF  TERMS  AND  SERVICES 

2.3  THE  SYSTEM  SECURITY  OFFICER 

2.4  USER  SECURITY  RESPONSIBILITIES 

3.  SECURITY-RELATED  COMMANDS  FOR  USERS 

3.1  SYSTEM  ACCESS 

3.1.1  Session  Initiation 

3.1.2  Changing  the  Session  Profile 

3.1.3  Changing  the  User  Profile 

3.1.4  Potential  Access  Problems  and  Solutions 

3.2  ACCESS  CONTROL  FACILITIES 

3.3  PROTECTING  REMOVABLE  OBJECTS 

3.4  LOGGING  SECURITY-RELEVANT  EVENTS 

The  annotated  outline  follows. 
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1.  INTRODUCTION  TO  THE  SFUG 

This  part  of  the  SFUG  should  identify  what  the  SFUG  is,  who  it  is  written  for, 
and  what  it  will  cover.  It  might  also  explain  where  the  SFUG  fits  in  with  the  rest  of 
the  user  documentation.  If  appropriate,  it  can  also  describe  the  relationship 
between  the  SFUG  and  the  TFM. 

2.  SYSTEM  SECURITY  OVERVIEW 

This  section  provides  the  background  on  the  overall  operation  of  the  security 
controls  in  the  system  so  that  users  can  then  understand  the  options  and  actions  of 
individual  security-relevant  commands. 

2.1  SYSTEM  PHILOSOPHY  OF  PROTECTION 

This  section  should  describe  the  general  environment  for  which  the  system  is 
designed  and  briefly  explain  how  this  environment  motivates  the  approach  to 
protecting  information  stored  in  the  system.  The  purpose  of  this  section  is  to  lay  the 
foundation  for  the  user’s  understanding  of  the  system’s  security  features,  with  later 
sections  detailing  what  specific  security  services  are  available  and  when  and  how  to 
use  them. 

2.2  DEFINITION  OF  TERMS  AND  SERVICES 

This  section  should  first  introduce  the  terms  that  will  be  used  to  describe  the 
security  services  available  in  the  system  and  then  proceed  to  introduce  those 
services,  without  detailing  exactly  how  they  are  used.  Recommended  topics  (and 
the  criteria  classes  for  which  they  are  relevant)  for  this  section  are: 

•  An  explanation  of  the  general  concepts  of  subjects  and  objects,  followed 
by  the  identification  of  the  subjects  and  objects  in  the  system. 

•  An  explanation  of  object  reuse  and  its  role  in  protecting  information  in  the 
system. 

•  An  explanation  of  the  components  of  the  l&A  (identification  and 
authentication)  process  (e.g.,  user-id,  password,  or  smartcard)  in  the  system  and  the 
importance  of  l&A  to  system  security. 
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•  An  explanation  of  DAC,  groups,  privileges,  protection  bits/ACLs  (access 
control  lists),  and  any  other  terms  and  concepts  related  to  the  system’s  DAC  policy, 
followed  by  a  description  of  how  the  DAC  policy  applies  to  the  system  subjects  and 
objects. 

•  An  explanation  of  MAC,  security  labels,  sensitivity  levels,  categories, 
authorizations,  and  any  other  terms  and  concepts  related  to  the  system’s  MAC 
policy,  followed  by  a  description  of  how  the  MAC  policy  applies  to  the  system 
subjects  and  objects. 

2.3  THE  INFORMATION  SYSTEM  SECURITY  OFFICER 

This  section  discusses  the  role  of  the  information  system  security  officer 
(ISSO)  in  maintaining  the  security  of  the  system.  It  can  also  explain  which  problems 
should  be  reported  to  the  ISSO  and  which  should  be  reported  to  the  system 
administrator  (if  the  roles  are  separate).  If  the  format  of  the  SFUG  allows  it,  this 
section  could  have  space  for  site-specific  notes  on  the  ISSO/user  relationship. 

2.4  USER  SECURITY  RESPONSIBILITIES 

This  section  discusses  the  user’s  responsibilities  with  respect  to  properly 
using  the  system  security  features.  This  would  optimally  be  a  tutorial  that  teaches 
effective  use  of  the  system  security  services,  but  any  presentation  that  relates  the 
security  services  to  the  user’s  day-to-day  use  of  the  system  is  appropriate.  Some 
issues  that  might  be  addressed  are: 

•  Authentication  token  (e.g.,  password  or  smartcard)  protection. 

•  Warnings  about  leaving  a  terminal  unattended. 

•  Procedures  for  “locking”  a  process  when  the  terminal  must  be  left 
unattended,  but  logged  in. 

•  Default  DAC  access  for  named  objects  (e.g.,  files  and  directories). 

•  Cautions  about  using  programs  that  are  not  part  of  the  standard  system 
configuration  (e.g.,  utilities  or  applications  that  have  not  been  reviewed  and  tested 
by  the  system  administrator(s)). 

•  Cautions  about  the  effect  of  network  access  on  system  and  data  security. 
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3.  SECURITY-RELATED  COMMANDS  FOR  USERS 

This  section  comprises  the  majority  of  the  SFUG  since  it  describes  in  detail 
the  commands  and  procedures  for  actually  using  the  system.  It  should  describe 
both  the  usage  of  the  commands  and  reemphasize  their  role  as  tools  to  protect 
information  stored  on  the  system.  For  example,  this  part  might  consist  of  command 
reference  pages  (e.g.,  UNIX  “man”  pages)  grouped  by  subject,  possibly  with  a  brief 
introduction  at  the  beginning  of  each  subject  area.  Alternatively,  this  section  could 
contain  general  descriptions  of  the  operation  and  options  of  individual  commands  or 
groups  of  commands,  along  with  pointers  to  the  detailed  documentation  of  the 
invocation  sequence(s)  for  the  commands. 

3.1  SYSTEM  ACCESS 

This  section  should  explain  the  procedures  for  logging  on  and  off  the  system. 
It  should  also  discuss  how  the  TCB  assigns  privileges  and  authorizations  during  the 
login  process  and  how  the  user  can  change  them  during  the  session  (if  the  system 
allows  in-session  changes).  This  section  might  also  discuss  how  users  can  prevent 
and  detect  compromise  of  their  accounts.  For  systems  that  provide  trusted  path 
during  a  session,  this  section  of  the  SFUG  should  describe  the  mechanism  for 
invoking  the  trusted  path  and  the  effect  of  the  invocation  on  the  currently  running 
process.  Finally,  the  errors  that  might  occur  during  the  use  of  these  commands  and 
corrective  actions  should  be  described  here. 

3.1.1  Session  Initiation 

This  section  should  describe  the  procedures  that  a  user  goes  through  to 
establish  a  session  with  the  system.  In  B2  and  above  systems,  this  discussion  will 
start  by  describing  how  a  user  establishes  a  trusted  path  between  the  terminal  and 
the  TCB.  For  any  system,  it  will  discuss  the  procedure  for  presenting  the 
identification  and  authentication  tokens  (typically  a  user-id  and  password)  to  the 
system  so  that  the  system  can  establish  a  subject  to  act  on  behalf  of  the  user. 
When  the  login  process  provides  the  means  for  overriding  the  default  group/project 
and  subject  sensitivity  level,  the  use  of  these  options  should  be  described. 
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3.1.2  Changing  the  Session  Profiie 

When  the  system  provides  the  facilities  for  the  user  to  dynamically  modify  his 
or  her  group/project  participation  and/or  subject  sensitivity  level,  this  section  should 
describe  them. 

3.1.3  Changing  the  User  Profile 

Many  systems  have  the  concept  of  a  user  profile,  which  contains  the  default 
settings  for  the  creation  of  a  user  subject.  Although  it  may  actually  be  maintained 
separately,  the  user  password  is  logically  part  of  this  profile.  This  section  should 
provide  information  on  how  to  modify  the  parts  of  the  user  profile  over  which  the 
user  has  control.  At  a  minimum,  this  section  should  show  how  the  user  can  change 
his  or  her  password  (for  systems  where  the  password  is  the  authentication  token). 

3.1.4  Potential  Access  Problems  and  Solutions 

This  section  should  discuss  the  possible  problems  that  a  user  could 
encounter  when  logging  into  the  system  or  modifying  session  and  user  profiles. 
This  section  could  be  organized  as  a  troubleshooting  guide,  where  each  problem 
and  its  potential  solution{s)  is  presented  in  a  table  format. 

3.2  ACCESS  CONTROL  FACILITIES 

This  section  describes  the  commands  available  to  a  user  for  managing  the 
objects  under  his  or  her  control.  The  major  issue  confronting  the  SFUG  author  in 
this  section  is  how  to  organize  the  commands.  Two  possible  options  are: 

•  By  security  policy  functionality,  i.e.,  all  commands  that  manipulate  MAC 
attributes,  DAC  attributes,  exportation  to  devices,  labeled  human-readable  output 
etc. 


•  By  target  object  class,  i.e.,  all  security-relevant  commands  that  manipulate 
files,  directories,  printers,  tape  drives,  interprocess  communication,  floppy  disks,  etc. 

Experience  during  previous  evaluations  indicates  that  the  second  option  more 
closely  matches  the  needs  of  the  user,  since  it  is  closer  to  the  organization 
expected  when  trying  to  search  for  a  specific  command  to  do  a  specific  job. 


28 


THE  TASK-ORIENTED  SFUG 


EXAMPLES  OF  SFUG  PRESENTATION  STYLES 


3.3  PROTECTING  REMOVABLE  OBJECTS 

This  section  should  discuss  some  of  the  basic  actions  that  a  user  should  take 
to  ensure  that  the  data  contained  in  hardcopy  or  external  storage  form  is  protected 
as  fully  as  when  it  is  on  the  computer  system.  In  a  site-specific  SFUG,  this  section 
could  be  an  even  stronger  statement  regarding  the  site’s  procedures  for  protecting 
information  once  it  leaves  the  system. 

3.4  LOGGING  SECURITY-RELEVANT  EVENTS 

In  some  systems,  it  may  be  possible  for  users  to  do  limited  auditing  on  the 
objects  over  which  they  have  control.  In  these  cases,  the  commands  available  to 
the  user  for  this  purpose  should  be  described. 
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-  SCOMP  User’s  Reference  Manual,  STOP  Release  2.1,  November  1984. 

12.  International  Business  Machines  Resource  Access  Control  Facility  (RACF), 
Version  1,  Release  5  (Final  Evaluation  Report),  DoD  Computer  Security 
Center,  CSC-EPL-84/001 ,  July  1984. 

This  PER  identified  the  following  document  as  the  SFUG  for  this  product: 

-  OS/VS2  MVS  Resource  Access  Control  Facility  (RACF):  General 

Information  Manual,  SC28-0722-6,  1984. 

13.  International  Business  Machines  Corporation  VM/SP  with  RACF  (Final 
Evaluation  Report),  National  Computer  Security  Center,  CSC-EPL-89/005, 
September  1989. 

This  PER  identified  the  following  six  documents  as  the  SFUG  for  this 
product: 

“Part  Three:  For  General  Users”  in  Virtual  Machine/System  Product  C2 

Security  Guide  VM/SP  Release  5  and  VM/SP  HPO  Release  5,  Library  Number 

SC24-5384-0,  no  date, 

-  RACF  General  User’s  Guide,  Library  Number  SC28-1341,  December  1987, 

-  VM/SP  CMS  Command  Reference,  Library  Number  SCI 9-6209,  no  date, 

-  VM/Directory  Maintenance  Operation  and  Use,  Library  Number  SC23-0437, 

March  1989, 

-  VMT APE-MS  User’s  Guide.  Library  Number  SH20-6245,  September  1988, 

The  VM  HELP  Facility,  online  function. 
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14.  Prime  Computer,  Inc  PRIMOS  Rev  21 .0.1  .DODC2A  (Final  Evaluation  Report), 
National  Computer  Security  Center,  CSC-EPL-88/009,  July  1988. 

This  PER  identified  the  following  document  as  the  SFUG  for  this  product: 
Security  Features  User’s  Guide,  1st  Edition  for  Revision  21.0,  1987. 

15.  UNISYS  Corporation  A  Series  MCP/AS  Release  3.7  (Final  Evaluation  Report), 
National  Computer  Security  Center,  CSC-EPL-87/003,  August  1987. 

This  PER  identified  the  following  document  as  the  SFUG  for  this  product: 

-  A  Series  Security  Features  Operations  and  Programming  Guide,  Document 
Number  1195203,  July  1987. 

16.  UNISYS  Corporation  OS  1100  (Final  Evaluation  Report),  National  Computer 
Security  Center,  CSC-EPL-89/004,  September  1989. 

This  PER  identified  the  following  document  as  the  SFUG  for  this  product: 
OS  1100  Security  System  Operations  Guide,  UP-13011.1,  August  1989. 
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